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From  the  Editor 

The  Simple  Network  Management  Protocol  (SNMP)  has  seen  wide- 
spread adoption  throughout  the  computer  industry.  Traditionally, 
SNMP  is  used  strictly  for  "network  management."  However,  experi- 
ence shows  that  there  is  also  a  need  to  manage  other  aspects  of  a 
distributed  computing  system.  The  term  "systems  management" 
refers  to  such  items  as  the  underlying  operating  system,  the  hard- 
ware, the  applications,  the  file  system,  and  so  on.  Our  first  article 
this  month  is  by  Bobby  Krupczak  and  describes  the  current  state 
and  future  prospects  for  systems  management  in  the  Internet  Frame- 
work. 

Most  Internet  standards  have  been  developed  by  a  number  of  Work- 
ing Groups  of  the  Internet  Engineering  Task  Force  (IETF).  The  IETF 
consists  of  a  number  of  Areas  focusing  on  specific  technologies.  Jim 
Galvin's  reports  from  the  Security  Area  have  become  an  almost 
regular  feature  in  Connexions,  and  we  bring  you  another  installment 
this  month.  In  addition,  Joyce  Reynolds  gives  us  an  overview  of 
another  IETF  area,  namely  User  Services. 

When  Connexions  began  publication  in  1987,  OSI  was  considered  by 
many  to  be  the  next  step  in  computer  networking.  For  a  number  of 
years,  OSI  versus  TCP/IP  became  the  topic  of  heated  arguments,  or 
"protocol  wars."  About  a  year  ago,  the  US  government  released 
POSIT  (a  revision  of  GOSIP)  which  officially  removed  its  mandate  to 
acquire  only  OSI  protocols.  Peter  Salus  asks  if  this  means  that  OSI 
is  dead  and  that  the  protocol  wars  are  over.  Readers  with  differing 
opinions  are  encouraged  to  respond. 

Following  the  dismantling  of  the  NSFNET  backbone  in  April  of  this 
year,  the  Internet  now  consists  of  a  number  of  Network  Access 
Points  (NAPs)  where  service  providers  and  other  networks  exchange 
traffic.  Some  aspects  of  this  new  system  /have  been  described  in 
previous  articles  in  Connexions.  This  month,  Jessica  Yu  describes 
the  Routing  Arbiter  Route  Server,  an  important  component  of  the 
new  system. 

Starting  with  this  issue,  our  subscription  service  will  be  handled  by 
Seybold  Publications  in  Media,  Pennsylvania.  The  800  number  re- 
mains unchanged,  but  for  callers  outside  the  United  States,  please 
note  that  you  should  now  call  -f-1  610-565-6864  for  subscription 
questions.  The  new  mailing  address  and  fax  appear  on  page  31. 

Finally,  if  you  receive  this  issue  as  a  free  sample  at  NetWorld-f 
Interop  95  in  Paris  or  Atlanta,  we'd  like  to  draw  your  attention  to  our 
special  conference  discount  rates.  To  subscribe  or  renew,  simply  com- 
plete the  enclosed  subscription  card  and  drop  it  in  the  mail. 
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Systems  Management  and  the 
Internet  Management  Fram.ework 

by  Bobby  Krupczak,  Empire  Technologies,  Inc. 

The  success,  popularity,  and  importance  of  using  the  Internet  Man- 
agement Framework  [3,13,14]  for  network  management  has  been  un- 
paralleled by  any  other  management  framework.  While  its  efforts 
were  originally  focused  on  the  monumental  task  of  managing  the  "net- 
work," managing  the  "systems"  connected  to  the  network  has  become 
increasingly  important  (Managing  the  systems  has  always  been  im- 
portant but  industry  and  the  IETF  focused  on  network  management 
first  mainly  because  of  its  more  pressing  needs.)  Indeed,  experience 
shows  that  without  the  correct  functioning  of  key  systems,  the  net- 
work becomes  unusable  from  a  user,  or  application,  perspective.  The 
need  for  a  consistent  method  for  the  management  of  valuable  system 
resources  and  mission-critical  applications  has  become  increasingly 
urgent  as  our  dependence  on  distributed  computing  continues  to  grow. 

Fortunately,  the  Internet  community  has  made  great  strides  toward 
specifying  a  common  interface  for  performing  systems  management 
by  defining  a  number  of  experimental  and  standards-track  Manage- 
ment Information  Base  (MIB)  modules  [1,2,8,9]  of  which  the  Host 
Resources  MIB  [10],  on  which  we  focus  here,  is  particularly  important 
for  managing  systems  and  their  resources.  However,  in  order  to  fully 
support  the  Host  Resources  MIB,  developers  of  the  underlying  sys- 
tems (OS,  device  drivers,  and  system  daemons)  must  provide  some 
means  of  accessing  information. 

We  focus  on  the  strengths  and  weaknesses  of  the  Host  Resources  MIB 
in  regards  to  systems  management  and,  based  on  implementation 
experience  presented  here,  identify  those  areas  which  require  more 
consistent  support  by  underlying  systems.  In  addition,  we  outline 
extensions  made  within  the  context  of  our  own  private-enterprise  MIB 
which  expand  the  scope  of  the  Host  MIB  (targeted  at  "generic"  hosts) 
to  provide  detailed  management  of  UNIX  systems.  This  article  is 
intended  for  those  interested  in  network  and  systems  management, 
and  especially  those  developing  hardware,  operating  systems,  and 
systems  applications.  It  is  hoped  that  these  experiences  will  provide 
sufficient  feedback  so  that  in  the  future  these  developers  may  include 
better  support  for  accessing  systems  management  information. 

This  article  is  organized  as  follows.  First  we  review  systems  manage- 
ment and  SNMP.  Then,  we  present  implementation-based  feedback 
on  the  Host  Resources  and  provide  an  overview  of  our  UNIX  manage- 
ment extensions. 

In  this  section  we  first  define  systems  and  network  management  and 
then  provide  some  motivations  for  their  integration.  We  then  review 
some  of  the  previous  work  on  systems  management  within  the  context 
of  the  Internet  Management  Framework. 

The  OSI  network  management  literature  [5,  6,  7]  defines  systems 
management  as  the  management  of  the  OSI  environment  (i.e.,  the 
components  providing  OSI  services).  It  does  not  necessarily  include 
the  underlying  hardware  and  systems  software  supporting  the  pro- 
vision of  OSI  services.  While  much  of  the  literature  has  used  the 
terms  network  and  systems  management  interchangeably,  they  have 
taken  on  different  meanings  than  that  used  in  the  OSI  literature.  We 
use  the  term  network  management  to  include  the  management  and 
operation  of  a  communications  subnetwork  and  the  services  it  pro- 
vides. 


The  Interoperability  Report 


Included  in  this  category  are  the  network  interface  cards,  the  protocol 
software,  routers,  bridges,  etc.  We  use  the  term  systems  management 
to  denote  the  management  and  operation  of  the  systems  in  which  net- 
worked components  reside.  Included  in  this  category  are  the  under- 
lying operating  system,  the  hardware  and  devices  on  which  the  sys- 
tem operates,  its  applications,  file  systems,  and  its  system  daemons. 

The  proliferation  of  scientific  and  engineering  workstations  running 
complex  operating  system  software  has  created  a  nightmare  for 
system  administrators.  Each  operating  system  defines  its  own  set  of 
system  administration  utilities  and  tools,  thus  requiring  administ- 
rators to  learn  multiple  interfaces  and  commands.  This  lack  of  a 
consistent  means  of  management  results  in  increased  costs  due  to 
training,  additional  administration  personnel,  and  vendor-specific 
administration  software.  However,  through  the  integration  of  systems 
and  network  management,  administrators  can  leverage  a  common, 
interoperable  and  standard  interface  for  the  administration  of  sys- 
tems. Further,  their  integration  can  also  permit  the  leveraging  of  net- 
work management  software  to  perform  systems  management 
functions.  Lastly,  this  integration  can  result  in  a  reduced  burden  on 
system  support  staff  and,  ultimately,  lower  management  costs. 

Interest  in  systems  management  via  SNMP  has  been  rising  since  the 
successful  deployment  of  MIB-II  (as  early  as  1991)  although  not  much 
has  been  published  regarding  its  use.  However,  a  few  MIBs  and 
papers  have  been  published.  The  overall  applicability  of  the  Internet 
Management  Framework  to  systems  management  is  explored  in  [11] 
along  with  a  discussion  on  a  UNIX  systems  management  MIB.  The 
Host  Resources  MIB  [10]  (see  Figure  1)  defines  a  set  of  managed 
objects  useful  for  systems  management. 
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Figure  1:  Host  Resources  MIB,  RFC  1514. 
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Systems  Management  (continued) 

It  is  defined  to  be  operating  system  independent  and  contains  objects 
defined  for  use  in  the  monitoring  of  devices,  storage  areas,  file  sys- 
tems, and  installed  software.  An  excellent  overview  of  this  MIB  and 
its  potential  use  can  be  found  in  an  earlier  Connexions  article  [16]. 
The  monitoring  of  critical  applications  has  been  proposed  in  several 
experimental,  application-specific  MIBs  [  1,  2,  8,  9,  12].  However,  as  of 
yet,  no  general,  flexible  framework  has  been  proposed  for  application 
management. 

In  this  section  we  present  experiences  gained  during  the  implement- 
ation of  the  Host  Resources  MIB  and  a  private-enterprise  UNIX 
management  MIB  on  two  of  the  major  flavors  of  UNIX  (BSD  and 
System  V).  This  implementation  has  been  deployed  across  a  large 
number  of  systems  in  a  variety  of  configurations.  We  first  concentrate 
on  the  Host  Resources  MIB  and  then  discuss  its  extensions  made 
within  our  own  private-enterprise  MIB.  Again,  while  an  earlier  article 
([16])  presents  the  many  benefits  of  the  Host  Resources  MIB,  we 
mainly  focus  on  the  experiences  gained  during  its  implementation  on 
real  systems. 

The  centerpiece  of  the  Host  Resources  MIB  is  the  hrDevice  group 
and  table.  This  group  and  table,  which  provide  information  about  the 
devices  (and  their  status)  contained  within  a  managed  system,  are 
extremely  useful  for  asset  management.  However,  complete  support 
for  this  group  is  entirely  dependent  on  the  underlying  operating 
system  and  its  support  for  an  API  to  the  kernel's  information  on  the 
hardware  and  devices  currently  in  operation.  While  an  application 
can  discover  some  devices  by  looking  through  certain  operating 
system  configuration  files  (e.g.,  /etc/mnttab  for  disks  and  partitions) 
or  by  simply  attempting  to  access  known  devices,  this  strategy  is 
unreliable  and  inherently  non-scalable.  Accessing  static  configuration 
files  is  often  incomplete  and  prone  to  errors  introduced  by  configur- 
ation changes.  Attempting  to  access  known  devices  is  inherently  non- 
scalable  since  the  agent  can  only  report  devices  it  knows  about  at 
compile-time.  Some  operating  systems  do  provide  access  to  the 
resources  known  by  the  operating  system.  On  these  systems,  agents 
can  rely  on  the  operating  system  to  inform  them  of  all  known  devices 
and  their  configuration.  However,  current  operating  systems  do  not 
generally  provide  runtime  access  to  each  device's  description,  manu- 
facturer, version,  etc. — information  important  for  asset  management. 
Some  devices,  notably  SCSI  disks  and  tape  drives,  do  provide  such 
access  through  well-defined  APIs.  It  is  our  belief  that  all  devices 
should  provide  some  well-known  API  for  accessing  basic  information 
about  its  manufacturer,  revision,  type,  etc.  and  that  operating  sys- 
tems should  make  all  relevant  device  information  available  to  applic- 
ation or  systems  programmers.  On  UNIX  systems,  a  system  defined 
ioctl  would  probably  be  sufficient. 

The  Host  Resources  MIB  defines  a  hrStorage  group  and  table 
designed  to  provide  information  about  the  logical  storage  areas  con- 
tained within  a  system.  However,  the  integration  of  buffer  subsystem 
statistics  into  the  hrStorageTable  is  problematic  due  to  several 
factors.  First,  the  hrStorageTable  does  not  really  define  a  storage 
type  for  operating  system  buffers;  a  MIB  implementor  must  choose 
between  random-access  memory  (RAM)  or  the  catch-all  "other"  for  the 
storage  type.  Choosing  the  storage  type  "RAM"  could  cause  confusion 
with  the  system's  total  RAM,  while  choosing  "other"  does  not  provide 
much  semantic  information. 


The  Interoperability  Report 


MIB-II  Correlation 


System  Configuration 


(      ) 


Installed  Software 


Further,  if  one  chose  RAM  for  the  storage-type,  there  could  be  overlap 
if  different  subsystems  define  buffers  of  the  same  size.  For  example,  in 
SunOS  systems,  buffer  statistics  for  the  Streams  and  BSD  network 
subsystems  as  well  as  the  general  I/O  buffer  cache  could  all  be  sup- 
ported. Clumping  all  buffer  information  together  as  RAM  would  be 
confusing  and  could  result  in  the  loss  of  management  information. 
One  solution  would  be  to  define  additional  storage  types  specifically 
for  buffers. 

The  hrNetworkTable  defines  a  table  for  network  devices  contained 
within  the  system.  One  of  its  columns,  hrNetworklf  Index,  identifies 
the  network  device's  corresponding  MIB-II  if  Table .  ifNumber  value. 
The  Host  Resources  MIB  does  not  define  a  return  value  to  use  if  this 
network  device  has  no  corresponding  MIB-II  ifTable  entry.  For 
example,  many  Sun  workstations  contain  an  ISDN  interface  which, 
technically,  is  a  network  interface  but  many  times  is  not  contained  in 
the  MIB-II  ifTable  because  it  is  not  currently  used  as  an  IP  network 
interface.  In  our  implementation,  we  return  the  value  of  0  in  such  a 
case.  The  MIB  specification  should  be  modified  so  that  a  value  of  0 
indicates  that  a  network  interface  is  not  currently  contained  in  the 
ifTable. 

The  Host  Resources  MIB  defines  only  a  handful  of  system  configur- 
ation variables  within  its  hrSystem  group.  Included  are  the  initial 
boot/load  device,  the  number  of  users,  and  the  maximum  number  of 
processes  allowed  by  the  system.  In  our  experience,  many  more  config- 
uration variables  are  possible  and  needed  to  properly  manage  a 
system  (regardless  of  its  operating  system).  One  alternative  is  to  try 
to  incorporate  these  variables  into  the  hrStorage  table.  For  example, 
one  could  construe  file  and  inode  lists  (or,  for  example,  their  DOS  and 
Windows  equivalents)  to  be  storage  areas  in  the  system  and  include 
their  allocation  information  in  the  hrStorage  table.  However,  the 
same  problems  arising  from  the  introduction  of  buffer  information  in 
the  hrStorage  also  arise  in  this  case  as  well. 

The  Host  Resources  MIB  defines  a  table  (hrSWInstalledTable) 
containing  an  entry  for  each  software  package  installed  on  the  sys- 
tem. There  are  two  problems  with  its  design  and  implementation. 
First,  the  table  does  not  contain  a  column  for  the  software  package's 
version.  Instead,  the  implementor  must  combine  the  software  version 
(if  it  is  known)  with  the  package's  name.  This  oversight  hinders  auto- 
mated management  since  human  intervention  will  probably  be  neces- 
sary in  order  to  interpret  what  portion  of  the  software  package's  name 
is  the  version.  Unfortunately,  type-casting  software  versions  into 
SNMP  defined  types  may  not  be  easy  since  vendors  often  use  incom- 
patible numbering  systems. 

Second,  not  all  operating  systems  (e.g.,  SunOS  and  other  BSD  derived 
systems)  support  a  unified  software  installation  and  packaging  for- 
mat. One  work-around  is  to  attempt  to  do  a  software  "discover";  how- 
ever, it  is  a  time-consuming  task  and  one  is  then  left  with  the  problem 
of  deciding  what  is  a  software  package  and  what  is  not.  Does  the 
agent  include  shell  scripts  and  system  binaries  as  software  packages? 
Microsoft  Windows  performs  a  software  "discover"  by  comparing  files 
it  finds  against  a  master  list.  While  this  strategy  might  be  practical  on 
PCs  with  limited  disk  space,  it  is  not  scalable  to  multi-user  systems 
with  large  amounts  of  internal  disk  storage.  Further,  with  such  a 
strategy,  the  master  list  of  known  software  is  frozen  at  the  time  the 
agent  is  distributed.  In  order  to  provide  support  for  newer  software 
packages,  the  agent  (or  its  software  list)  would  also  need  to  be  up- 
dated. 

continued  on  next  page 
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Systems  Management  (continued) 

The  Host  Resources  MIB  defines  an  object  identifier  textual  con- 
vention, ProductlD,  that  is  intended  to  identify  the  manufacturer, 
model,  and  version  of  a  hardware  item  or  software  package.  At  pre- 
sent, few  hardware  or  software  vendors  support  it;  indeed,  conform- 
ance with  this  aspect  of  the  MIB  was  cause  of  some  debate  within  the 
original  working  group.  If  vendors  begin  to  comply,  it  is  important 
that  they  support  the  ability  to  dynamically  determine  the  ProductlD 
so  as  to  avoid  requiring  agents  to  maintain  lists  of  ProductlD  to 
vendor  mappings.  For  UNIX  systems,  a  well-known  ioctl  could  be 
defined  such  that  its  return  value  is  a  device  or  kernel  module's 
ProductlD.  Application  software  should  support  ProductlDs  as  part 
of  installation  information. 

The  Host  Resources  MIB  defines  tables  containing  disk  information, 
disk  partitions,  and  file  systems  residing  within  the  managed  system. 
Starting  with  the  disk  table,  managers  may  then  examine  that  disk's 
partitions  and  then  examine  a  given  partition's  file  system.  In  order  to 
properly  support  all  disks  (not  just  those  that  have  file  systems  and 
are  mounted),  the  operating  system  must  provide  information  about 
all  known  devices.  Second,  it  must  support  manufacturer-independent 
methods  of  obtaining  configuration  information  such  as  capacity,  file 
system  layout,  etc.  Lastly,  the  hrFSTable  defines  columns  identifying 
the  last  full  and  partial  backup  dates.  Unfortunately,  there  are  a 
myriad  (e.g.,  bar,  tar,  dump)  of  backup  programs  and  techniques 
which  each  store  backup  times  (if  at  all)  in  an  incompatible  manner. 
What  is  needed  is  a  consistent  method  for  storing  backup  times  for 
partitions  and  file  systems.  One  solution  would  be  to  have  a 
partition's  backup  times  stored  within  the  disk's  label  along  with  the 
normal  partition  and  cylinder  information. 

The  Host  Resources  MIB  continues  the  tradition  of  defining  MIB 
objects  without  endowing  the  agent  or  MIB  (depending  on  your  per- 
spective) with  "intelligence"  for  distributed  self-management.  Other 
MIBs,  most  notably  the  Remote  Network  Monitoring  MIB  [15]  and  the 
Manager-to-Manager  MIB  [4],  are  able  to  endow  agents  with  intelli- 
gence, yet  still  conform  to  the  philosophies  of  the  Internet  Manage- 
ment Framework.  The  Host  Resources  MIB,  however,  defines  no  traps 
or  self-monitoring  capabihties;  consequently,  managers  must  (perhaps 
unavoidably)  poll  the  agent. 

Despite  these  issues,  the  Host  Resources  MIB  is  extremely  useful  for 
managing  systems.  Its  device  and  installed-software  tables  are  excel- 
lent for  asset  tracking  and  management.  Its  disk,  partition,  and  file 
system  tables  coupled  with  the  Host  Resources  system  group  are 
useful  for  configuration  management.  Finally,  its  "standard"  nature 
makes  it  easier  for  management  station  applications  to  code  towards 
a  vendor-independent  format. 

Because  the  Host  Resources  MIB  specification  focuses  on  those 
aspects  common  to  all  computer  systems,  it  may  not  completely  satis- 
fy the  management  requirements  of  a  particular  system  (e.g.,  UNIX). 
Consequently,  we  have  evolved  our  own  private-enterprise  MIB  to 
extend  the  systems  management  capabilities  of  the  Host  Resources 
MIB.  More  specifically,  we  have  geared  (at  present)  our  MIB  specific- 
ation to  the  task  of  managing  UNIX  and  UNIX-like  operating  sys- 
tems. Our  extensions  have  been  twofold.  First,  we  have  defined  and 
implemented  additional  MIB  objects  important  to  the  management  of 
UNIX  systems.  Second,  we  have  begun  defining  and  implementing 
"RMON"-like  extensions  for  systems  management.  We  discuss  these 
complimentary  directions  below. 


r\ 


'} 


The  InteroperabUity  Report 


/ 


(    ) 


Our  first  task  was  the  definition  and  implementation  of  a  range  of 
MIB  objects  important  to  the  management  of  UNIX  and  UNIX-Uke 
operating  systems.  We  added  extensive  kernel  configuration  para- 
meters covering  everything  from  file  table  sizes,  swap  space,  and  the 
BSD  and  Streams  I/O  subsystems.  Next,  we  added  extensive  process 
information  to  augment  that  contained  in  the  Host  Resources 
hrSWRunTable  and  hrSWRunPerfTable.  For  example,  we  report  a 
process'  owner  and  group  as  well  as  its  process-ID,  size,  and  nice 
value.  Because  of  the  importance  of  memory  buffers,  we  created  a 
separate  group  for  buffer  statistics  and  separated  them  by  their 
respective  subsystems  (e.g.,  strbufs  and  mhufs).  We  also  added  inform- 
ation about  a  system's  valid  users  and  groups  as  well  as  information 
about  who  is  currently  logged  on  and  using  the  system.  Since  inform- 
ation about  valid  users  and  groups  can  be  sensitive  (for  security 
purposes),  we  also  added  the  ability  to  selectively  "turn  on  or  off" 
support  for  these  groups.  (More  sophisticated  MIB  views  within  the 
context  of  the  SNMPv2  administration  model  would  be  a  more  general 
solution  though).  While  the  Host  Resources  MIB  tends  to  focus  on 
configuration  and  asset  management,  we  added  support  for  perform- 
ance management  by  adding  MIB  objects  for  tracking  kernel,  disk, 
and  memory  performance  statistics.  Lastly,  we  added  a  range  of  coun- 
ters and  statistics  necessary  for  monitoring  NFS  and  RFC  services 
due  to  their  importance  in  distributed  environments. 

Our  second  task  was  the  definition  of  "RMON"-like  extensions  for 
systems  management  whereby  we  endow  agents  with  intelligence,  yet 
still  conform  to  the  goals  of  the  Internet  Management  Framework. 
.  Our  motivations  are  based  primarily  on  the  need  to  provide  a  scalable 
systems  and  network  management  solution  to  large,  distributed  net- 
works of  workstations.  By  endowing  an  agent  with  intelligence  and 
autonomy,  we  can  reduce  network  and  system  load  due  to  polling  and 
instruct  the  agent  on  how  to  behave  in  certain  circumstances.  Our 
"RMON"-like  extensions  have  taken  (so  far)  two  forms. 

First,  we  have  defined  a  monitor  table  (roughly  equivalent  to  the 
RMON's  alaritiTable)  that  enables  a  manager  to  instruct  an  agent  to 
monitor  certain  MIB  objects  and  to  send  a  TRAP  message  when  some 
threshold  is  crossed.  Each  monitor  entry  defines  a  Boolean  expression, 
that  when  evaluated  to  True,  indicates  that  an  event  has  occurred. 
For  example,  using  the  monitor  table,  a  manager  can  instruct  an 
agent  to  send  a  TRAP  message  when  a  certain  disk  or  file  system 
becomes  95%  full;  alternatively,  a  manager  can  instruct  an  agent  to 
send  a  TRAP  when  an  important  process  (e.g.,  sendmail  )  dies  or 
becomes  a  zombie.  Second,  we  are  defining  and  implementing  a 
history  mechanism  whereby  a  manager  can  instruct  an  agent  to 
sample  and  store  the  value  of  a  MIB  object  over  time.  Like  the  RMON 
MIB  [15],  we  have  defined  history  and  history  control  tables  and  the 
notion  of  sample  buckets.  Sample  buckets  serve  to  place  an  upper 
bound  on  the  resources  the  agent  devotes  to  a  particular  history 
control  entry. 

For  example,  using  this  facility,  managers  can  instruct  the  agent  to 
sample  and  record  the  length  of  the  run  queue,  the  amount  of  network 
I/O,  the  size  of  a  given  process,  or  the  amount  of  allocated  and  free 
buffer  space  over  some  interval.  This  type  of  functionality  (monitoring 
and  recording)  is  crucial  for  the  proper  tuning  of  UNIX  systems. 
Although  we  have  initially  geared  our  MIB  towards  the  task  of 
managing  UNIX,  there  is  nothing  in  our  "RMON"-like  extensions  that 
is  necessarily  specific  to  UNIX. 

continued  on  next  page 
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Consequently,  these  extensions  may  be  leveraged  for  the  management 
of  other  operating  systems.  Finally,  because  these  extensions  have 
been  patterned  after  the  RMON  MIB,  we  hope  to  leverage  RMON 
m^anagement  software. 

Conclusion  The  Host  Resources  MIB  is  a  great  start  toward  the  goal  of  inte- 
grating network  and  systems  management.  What  we  have  focused  on 
is  experiences  gained  from  its  implementation  on  two  major  flavors  of 
UNIX.  However,  due  to  its  goal  of  being  generic,  some  potential 
manageability  of  UNIX  systems  is  not  realized.  Consequently,  we 
have  evolved  our  own  private-enterprise  MIB  by  adding  MIB  objects 
more  specific  to  the  task  of  managing  UNIX  and  by  defining  "RMON"- 
like  functionality  for  managing  systems.  It  is  hoped  that  these  experi- 
ences will  guide  future  system  developers  in  making  their  systems 
more  "management-ready"  for  those  implementing  systems  manage- 
ment agents. 
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Spring  IETF  Meeting  Security  Activities 

by  Jim  Galvin,  Trusted  Information  Systems 

The  Internet  Engineering  Task  Force  (IETF)  met  in  Danvers,  Massa- 
chusetts, April  3-7,  1995.  The  IPv6  security  requirements  received 
considerable  attention  during  the  open  Internet  Engineering  Steering 
Group  (lESG)  meeting.  As  reflected  in  the  IP  next  generation  protocol 
recommendation  (RFC  1752),  published  as  a  Proposed  Standard  in 
January  1995,  IPv6  requires  authentication  and  encryption  to  be 
available  at  all  times  and  authentication  to  be  enabled  by  default. 

All  of  the  usual  perspectives  were  expressed,  including: 

®  Political:  With  the  export  restrictions  such  as  they  are,  why 
bother? 

®  Technical:  Is  DES  the  best  choice  for  an  encryption  algorithm? 

«»  Emotional:  We  need  security  now!  We  need  standards  to  guaran- 
tee interoperability!  Do  something! 

No  consensus  was  reached  but  none  had  been  expected.  It  was  impor- 
tant, however,  for  opinions  to  be  expressed,  and  the  lESG  should 
consider  them  in  future  deliberations  of  IP  next  generation  specific- 
ations. 

Fewer-than-usual  security  activities  occurred  at  this  meeting.  The 
Privacy  Enhanced  Mail  (PEM)  working  group  did  not  meet.  Docu- 
ments are  awaiting  final  review  by  the  group  and  subsequent  sub- 
mission to  the  lESG  for  publication  as  proposed  standards.  The  PEM 
and  MIME  integration  protocol  being  proposed  is  now  called  MIME 
Object  Security  Services  (MOSS). 

The  Domain  Name  System  Security  (DNSSEC)  working  group  did  not 
meet,  although  the  latest  version  of  the  specification  is  under  revision, 
largely  due  to  the  implementation  efforts  of  Trusted  Information 
Systems.  The  Secure  HTTP  birds  of  a  feather  (BOF)  held  at  the  last 
meeting  did  not  submit  a  charter  (the  minimum  requirement  for 
becoming  a  working  group).  However,  it  was  announced  at  this 
meeting  that  a  new  working  group  would  be  formed,  Web  Transport 
Security,  the  scope  of  which  includes  the  work  proposed  by  the  Secure 
HTTP  BOF. 

Finally,  the  IP  Security  working  group  met  only  once  during  this 
week,  in  contrast  to  its  tradition  of  multiple  meetings.  As  usual,  the 
meeting  was  lively,  and  discussions  continue  on  the  mailing  list.  Con- 
sensus was  reached  on  requiring  the  implementation  of  a  hybrid 
Diffie-Hellman  key  exchange  for  the  Internet  Key  Management  Proto- 
col (IKMP).  The  Photuris  specification  will  be  progressed  in  the  work- 
ing group  as  the  baseline  description  of  this  key  exchange.  Additional 
presentations  were  given  on  possible  modifications  to  the  Photuris 
exchange  and  on  a  framework  for  the  IKMP  protocol  signaling. 

A  summary  of  security-relevant  working  groups  and  BOF  sessions 
follows. 

The  working  group  charter  is  being  revised  to  include  a  scope  com- 
patible with  Independent  Data  Unit  Protection  (IDUP)  and  with  future 
authorization  support  facilities.  The  following  documents  are  eligible 
for  the  issuance  of  a  working  group  last  call  (as  indicated)  in  advance 
of  their  submission  to  the  lESG  for  publication  as  Proposed  Stan- 
dards. 
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The  FTP  Security  specification  has  been  resurrected  with  a  new 
editor,  March  Horowitz.  A  revised  specification  is  expected  to  be 
available  soon. 

A  revision  of  Version  2  of  the  GSS  specification  and  C  bindings 
documents  is  expected  to  be  available  soon. 

The  Simple  Public  Key  Mechanism  is  considered  stable  at  this  time, 
pending  resolution  of  an  issue  identified  regarding  X9.44  replay 
protection,  and  was  placed  in  working  group  last  call  on  April  5,  prior 
to  its  submission  to  the  lESG  for  publication  as  a  Proposed  Standard. 

RFC  1510  (Kerberos)  is  now  eligible  for  advancement  to  a  Draft 
Standard.  One  remaining  issue  relevant  to  the  document's  advance- 
ment will  be  resolved  on  the  mailing  list. 

NetScape  gave  a  presentation  on  the  Secure  Socket  Layer.  An  Inter- 
net-Draft is  expected  to  be  available  soon. 

Discussion  continues  on  the  other  documents  and  activities. 

The  Guidelines  and  Recommendations  for  Security  Incident  Proces- 
sing (GRIP)  is  part  of  the  Operational  Requirements  Area  but  is 
tracked  by  the  Security  Area.  This  new  working  group  has  drafted 
guidelines  for  security  incident  response  teams.  A  revised  draft  is 
expected  to  be  available  soon,  at  which  time  a  working  group  last  call 
will  be  issued.  The  document  will  be  submitted  to  the  lESG  for 
publication  as  a  Proposed  Standard  by  the  next  IETF. 

The  Router  Requirements  working  group  has  a  document  ready  to 
submit  to  the  lESG  for  publication  as  a  Proposed  Standard.  It  will 
include  a  requirement  level  of  SHOULD  for  strong  remote  authenticr 
ation.  The  use  of  security  by  routing  protocols  is  an  issue  to  be 
resolved  before  the  document  advances  to  Draft  Standard. 

More  information       For  more  information  see:  http:  //www.ietf  .cnri.reston.va.us/ 

[Ed.:  The  next  IETF  meeting  was  held  in  Stockholm,  Sweden,  July 
17-21,  1995.  We  hope  to  bring  you  another  IETF  security  update  from 
the  Stockholm  meeting  in  a  future  issue.] 
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The  User  Services  Area  of  the  IETF 

by  Joyce  K.  Reynolds,  ISI 

When  the  Internet  Engineering  Task  Force  (IETF)  was  first  estab- 
Ushed,  it  did  not  immediately  create  a  distinct  User  Services  Area. 
Since  1991,  this  area  has  grown  to  take  its  place  with  other  Internet 
Engineering  Steering  Group  (lESG)  areas  as  the  importance  of  the 
user  has  increased  globally.  This  area  provides  an  international  forum 
for  people  interested  in  all  levels  of  user  services,  to  identify  and  initi- 
ate projects  designed  to  improve  the  quality  of  the  information  avail- 
able to  users  of  the  Internet. 

One  continuing  goal  of  the  User  Services  Area  is  to  coordinate  the 
development  of  user  information  services  by  clearly  and  concisely 
providing  documentation  information  and  distribution  for  the  Inter- 
net community.  FYI  {For  Your  Information)  RFCs  {Request  for  Com- 
ments) are  introductory  and  overview  documents  for  network  users. 
Their  purpose  is  to  make  available  general  information,  rather  than 
the  protocol  specifications  or  standards  that  is  typical  of  other  RFCs. 
FYIs  are  allied  to  the  RFC  series  of  notes,  but  provides  information 
about  who  does  what  on  the  Internet.  The  FYI  RFC  series  has  proved 
a  success  since  its  initiation,  and  its  goal  is  to  continue  to  do  so.  A 
current  list  of  FYI  RFCs  are  listed  at  the  end  of  this  article. 

The  actual  projects  of  the  User  Services  Area  are  handled  by  the  cre- 
ation of  Working  Groups  (WGs).  There  are  currently  ten  working 
groups  in  this  area,  as  summarized  in  Table  1  below. 

Mailing  List 


WG 


Chair(s) 


HARTS 

Scott  Stoner 
Susan  Siegfried 

harts@isi.edu 

IDS 

Linda  Millington 
Sri  Satalur 

ids@merit . edu 

ISN 

Jennifer  Sellers 
Jodi  Chu 

isn-wg@nasa . gov 

NISI 

April  Marine 

nisi@merit . edu 

RUN 

Sally  Hambridge 
Gary  Malkin 

ietf -run@mailbag . intel .c 

SSH 

Barbara  Fraser 

ssh@cert.org 

TRAINMAT 

Jill  Foster 
Mark  Prior 

us -wg@nic . near . net 

URI 

Larry  Masinter 

uri@bunyip . com 

USERGLOS 

Gary  Malkin 

usergloss@xylogics . com 

USWG 

Joyce  K.  Reynolds 

us-wg@nic.near.net 
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Table  1:  IETF  User  Services  Area  June  1995 

«  Humanities  and  Arts  (HARTS):  The  HARTS  Working  Group  has 
identified  three  goals  to  be  pursued.  The  first  goal  is  development  of  a 
FAQ  {Frequently  Asked  Questions)  regarding  value  and  role  of  the 
arts  in  the  Internet.  The  second  goal  is  to  define  tools  for  artists' 
organizations  on  the  Internet  which  will  focus  on  creating,  viewing, 
and  storage  formats  for  arts  humanities  resources.  This  will  include 
contributions  regarding  text,  sound,  still  and  motion  images. 
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It  will  address  different  operating  systems,  glossary  of  basic  termin- 
ology and  a  bibliography.  The  third  goal  is  to  further  define  issues 
surrounding  copyright  and  intellectual  property,  funding,  and  other 
support  for  arts  humanities  participation  and  any  other  needs  identi- 
fied by  the  survey. 

®  Integrated  Directory  Services  (IDS):  The  IDS  Working  Group  is 
chartered  to  facilitate  the  integration  and  interoperability  of  current 
and  future  directory  services  into  a  unified  directory  service.  This 
work  will  unite  directory  services  based  on  a  heterogeneous  set  of 
directory  services  protocols  (X.500,  WHOIS++,  etc.).  In  addition  to 
specifying  technical  requirements  for  the  integration,  the  IDS  Group 
will  also  contribute  to  the  administrative  and  maintenance  issues  of 
directory  service  offerings  by  publishing  guidelines  on  directory  data 
integrity,  maintenance,  security,  and  privacy  and  legal  issues  for 
users  and  administrators  of  directories. 

»  Internet  School  Networking  (ISN):  ISN  is  chartered  to  address 
issues  related  to  the  connection  of  primary  and  secondary  schools 
worldwide  to  the  Internet.  The  key  audiences  include  network  service 
providers  and  educational  policy  makers  responsible  for  network 
access  and  use.  The  key  areas  of  focus  for  this  group  are  advocacy  and 
articulation. 

»  Internet  User  Glossary  (USERGLOS):  USERGLOS  is  chartered  to 
create  an  Internet  glossary  of  networking  terms  and  acronyms  for  the 
Internet  community.  The  WG  will  update  the  existing  Internet  Users' 
Glossary  (RFC  1392,  FYI  18),  which  is  now  over  two  years  old.  The 
group  will  make  any  necessary  corrections  and  add  new  terminology 
which  has  evolved  since  the  last  edition  was  created. 

®  Network  Information  Services  Infrastructure  (NISI):  NISI  is  explor- 
ing the  requirements  for  common,  shared  Internet-wide  network 
information  services.  The  goal  is  to  develop  an  understanding  for 
what  is  required  to  implement  an  information  services  "infrastruct- 
ure" for  the  Internet. 

•  Network  Training  Materials  (TRAINMAT):  TRAINMAT  is  char- 
tered to  enable  the  research  community  to  make  better  use  of  the  net- 
worked services.  Towards  this  end,  the  Working  Group  will  work  to 
provide  a  comprehensive  package  of  "mix  and  match"  training  materi- 
als for  the  broad  academic  community  which  will:  1)  enable  user 
support  staff  to  train  users  to  use  the  networked  services  and  2) 
provide  users  with  self-paced  learning  material.  In  the  first  instance, 
it  will  not  deal  with  operational  training.  This  Working  Group  is  the 
IETF  component  of  a  joint  TERENA/IETF  group  working  on  Network 
Training  Materials. 

»  Responsible  Use  of  the  Network  (RUN):  RUN  is  chartered  to  create 
an  etiquette  ("netiquette"  in  network  parlance)  guide  for  Internet 
users.  The  working  group  will  develop  an  FYI  RFC  on  responsible  use 
of  the  Internet  and  its  tools. 

»  Site  Security  Handbook  (SSH):  SSH  is  chartered  to  create  two  docu- 
ments: (1)  a  revised  handbook  that  will  help  system  and  network 
administrators  develop  their  own  site-specific  policies  and  procedures 
to  deal  with  computer  security  problems  and  their  prevention  and  (2) 
a  new  handbook  for  users.  The  text  of  these  documents  will  be  devel- 
oped from  the  existing  RFC  1244,  plus  needed  revisions  and 
additions. 
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®  Universal  Resource  Identifiers  (URI):  URI  is  chartered  to  define  a 
set  of  standards,  for  the  encoding  of  system  independent  Resource 
Location  and  Identification  information  for  the  use  of  Internet  inform- 
ation services. 

®  User  Services  (USWG):  The  User  Services  Working  Group  provides 
a  regular  forum  for  people  interested  in  all  user  services  to  identify 
and  initiate  projects  designed  to  improve  the  quality  of  information 
available  to  end-users  of  the  Internet. 

References       The  FYI  RFC  Series  of  Internet  Documentation  listed  below  was 
developed  specifically  for  Users  (not  Wizards!) 
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March  1994. 
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(Also  RFC  1578),  February  1994. 
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1993. 
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utions Should  Anticipate,"  (Also  RFC  1359),  August  1992. 

[13]  FYI  15  "Privacy  and  Accuracy  Issues  in  Network  Information 
Center  Databases,"  (Also  RFC  1355),  August  1992. 
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[15]  FYI  13  "Executive  Introduction  to  Directory  Services  Using  the 
X.500  Protocol,"  (Also  RFC  1308),  March  1992. 

[16]  FYI  12  "Building  a  Network  Information  Services  Infrastruc- 
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How  to  get  RFCs       Details  on  obtaining  FYI  RFCs  via  FTP  or  e-mail  may  be  obtained  by 

sending  an  e-mail  message  to  rfc-info@isi.edu  with  the  message 
body  "help :    ways_to_get_rf  cs . "  For  example: 

To:  rfc-info@isi.edu 
Subject:  getting  rfcs 
help:  ways_to_get_rfcs 

JOYCE  K.  REYNOLDS  has  been  affiliated  with  USC/Information  Sciences  Insti- 
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Protocol  (FTP).  Ms.  Reynolds  is  an  Internet  Engineering  Steering  Group  (lESG) 
member  of  the  Internet  Engineering  Task  Force  (IETF).  She  established  a  new 
informational  series  of  notes  for  the  Internet  community:  FYI  (For  Your  Inform- 
ation) RFCs.  FYI  RFCs  are  documents  useful  to  network  users.  Their  purpose  is  to 
I  make  available  general  and  useful  information  with  broad  applicability.  As  chair  of 

§)  the  User  Services  Area  Council  (USAC),  the  coordinating  committee  for  the  IETF 

User  Services  Area,  she  provides  leadership  in  the  international  user  services 
arena.  Ms.  Reynolds  received  Bachelor  of  Arts  and  Master  of  Arts  degrees  in  the 
Social  Sciences  from  the  University  of  Southern  California  (USC).  She  is  the  past 
Associate  Editor  of  the  Internet  Society  News.  E-mail:  jkreyOisi .  edu . 
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Protocol  Wars:  Is  OSI  Finally  Dead? 

by  Peter  H.  Salus 

If  you're  "on  the  net,"  you  know  about  TCP/IP.  But  that's  not  the 
"official"  protocol  suite.  The  International  Organization  for  Standardi- 
zation (ISO)  legislated  something  else  (called  OSI  in  1978)  and  the 
National  Bureau  of  Standards  (now  NIST)  went  along  with  it.  There's 
been  a  lot  of  strife  over  the  past  17  years. 

But  now,  in  line  with  peace  in  Northern  Ireland  and  in  the  Middle 
East,  NIST  seems  to  have  declared  an  end  to  protocol  wars  after  near- 
ly two  decades.  On  September  16,  1994,  a  notice  was  entered  in  the 
Federal  Register  for  a  "new  FIPS  that  renames  GOSIP  to  'Profiles  for 
Open  Systems  Internetworking  Technologies  (POSIT)'  FIPS  146-2." 
This  Federal  Information  Processing  Standard  will  remove  the  man- 
date to  acquire  only  OSI  protocols. 

My  guess  is  that  wild  cheers  have  rung  out  in  networking  centers  all 
over  North  America.  Publication  in  the  Federal  Register  marked  the 
beginning  of  the  required  45-day  comment  period,  which  (appropri- 
ately) ended  just  after  Halloween  1994.  Revised  publication  occurred 
in  May,  1995. 

FIPS  146-2  recommends  the  use  of  IGOSS-NIST  SP  500-217  to 
agencies  wishing  to  acquire  computer  networking  products  based  on 
the  OSI  standards.  For  IPS  guidance,  the  FIPS  146-2  makes  general 
reference  to  the  IETF  voluntary  standards  and  specific  reference  to 
RFC  1610.  Finally,  the  reference  to  the  Government  Network  Manage- 
ment Profile  (GNMP)  FIPS  179-1  will  be  removed. 

GOSIP  required  US  agencies  to  procure  equipment  that  could  run  the 
ISO-OSI  (International  Organization  for  Standardization  Open  Sys- 
tems Interconnection)  network  protocols.  As  the  government  is  such  a 
large  customer,  this  meant  that  vendors  added  OSI  (or  at  least  soft- 
ware that  looked  as  though  OSI  protocols  could  be  added)  to  their 
networking  software  to  qualify  for  agency  sales. 

GOSIP  never  required  anyone  to  use  OSI,  merely  to  obtain  it.  Vendors 
also  supplied  the  TCP/IP  suite,  and  that  is  what  was  used,  not  only  in 
the  US,  but  in  much  of  Europe  and  Asia.  GOSIPs  main  effect  was  in 
getting  vendors  to  supply  OSI. 

GOSIP  has  also  had  a  high  political  profile.  Some  folks  believed  that  it 
would  precipitate  a  shift  away  from  TCP/IP  to  OSI.  It  never  hap- 
pened, and  now  OSI  is  moribund  and  GOSIP  is  changing  in  a  drastic 
fashion. 

GOSIP  Version  1  was  approved  as  a  draft  in  October  1988,  as  a  Full 
Use  version  in  NIST  Special  Publication  500-187.  It  specified  the  OSI 
protocol  stack.  The  current  version  is  GOSIP  Version  2  (FIPS  146-1;  3 
April  1991). 

GOSIP  Version  2  was  a  watered  down  version.  It  contained  the 
Connectionless  Network  Protocol,  also  known  as  ISO-IP.  CLNP  is  the 
Internet  Protocol  (IP)  with  a  bigger  address  space.  But  it  isn't  IP. 
Networks  built  from  it  won't  interoperate  with  the  Internet  without 
conversion  software.  So  GOSIP-2  required  agencies  to  acquire  prod- 
ucts with  two  sets  of  protocols,  only  one  of  which,  TCP/IP,  would  be 
used. 

On  16  September  1994,  NIST  entered  a  notice  in  the  Federal  Register 
for  a  FIPS  146-2  that  renames  GOSIP  to  Profiles  for  Open  Systems 
Internetworking  Technologies  (POSIT). 
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This  new  FIPS  removes  the  requirement  to  procure  only  OSI  proto- 
cols. It  does  include  a  recommendation  for  what  to  use  if  an  agency 
wants  to  acquire  OSI,  but  it  does  not  require  acquiring  OSI.  For 
general  use,  POSIT  refers  to  the  Internet  Standards  specified  by  the 
Internet  Engineering  Task  Force  (IETF).  The  most  specific  reference  is 
to  RFC  1601,  which  describes  the  Internet  Architecture  Board  (lAB), 
which  is  the  parent  organization  of  the  IETF,  and  RFC  1602  which 
describes  the  Internet  standardization  process  itself.  These  Internet 
Standards  are  of  course  the  specifications  of  the  TCP/IP  protocols, 
including  IP. 

Translation:  GOSIP  is  dead,  and  the  U.S.  Government  is  formally 
acknowledging  that  TCP/IP  is  preferable  to  OSI. 

Bizarrely,  ARPA  was  the  principal  funder  for  the  original  TCP/IP 
protocol  suite.  When  Vint  Cerf  (now  at  MCI)  and  Bob  Kahn  (now  at 
CNRI)  came  up  with  their  ideas  twenty  years  ago,  ARPA,  NASA,  and 
NSF  fostered  the  development  of  the  protocols.  The  "big  switch"  on 
January  1,  1983,  from  the  Network  Control  Protocol  to  TCP/IP  was 
encouraged  by  the  US  agencies.  And  in  1983,  the  Defense  Com- 
munications Agency  bought  in  to  the  suite  as  well. 

The  phenomenal  growth  of  the  Internet  is  the  direct  result  of  the  fact 
that  it  is  built  upon  these  protocols. 

A  historical  view       A  glance  at  the  history  explains  why  TCP/IP  succeeded  where  OSI  did 

not. 

In  1977,  the  British  Standards  Institute  proposed  to  ISO  that  a 
standard  architecture  was  needed  to  define  the  communications  infra- 
structure. (This,  as  with  IFIP,  CCITT  and  other  efforts,  shows  hoNv 
the  road  to  hell  is  paved  with  good  intentions.  Because  X.25  was 
unsatisfactory,  the  IFIP  Working  Group  was  set  up  in  the  hope  that 
the  technological  community  could  forestall  the  political  arena  of  ISO. 
It  didn't.)  ISO  set  up  a  subcommittee  of  a  technical  committee  to 
study  this  [ISO/TC  97/SC  16]. 

The  next  year,  1978,  ISO  published  its  "Provisional  Model  of  Open 
Systems  Architecture"  [ISO/TC  97/SC  16  N  34].  This  was  labelled  a 
"Reference  Model,"  and  referred  to  as  ISORM  (ISORM— pronounced 
"eye-sorm"  by  Mike  Padlipsky)  [24].  In  general,  it  was  based  on  work 
done  by  Mike  Canepa's  group  at  Honeywell  Information  Systems, 
which  came  up  with  a  seven-layered  architecture,  which  itself  owed 
much  to  IBM's  proprietary  Systems  Network  Architecture  (SNA).  SNA 
had  been  announced  in  1974  and  its  seven  layers  don't  correspond 
exactly  to  OSI/ISORM's.  TC  97/SC  16  turned  over  proposal  develop- 
ment to  the  American  National  Standards  Institute  (ANSI),  to  which 
Canepa  and  his  technical  lead,  Charlie  Bachman,  presented  their 
layered  model.  This,  in  turn,  was  the  only  proposal  presented  to  the 
ISO  subcommittee,  at  a  meeting  in  Washington  in  March,  1978.  It 
was  accepted  and  published  immediately. 

A  "refined"  version  of  the  ANSI  submission  to  ISO  appeared  in  June 
1979.  This  published  version  is  nearly  identical  to  Honeywell's  version 
of  1977.  After  an  elaborate  set  of  meetings,  four  International  Stan- 
dards were  legislated.  The  extant  NCP  (host-host  protocol)  did  not  fit 
ISORM.  ISO  was  trying  to  construct  a  nice  set  of  geometric  figures 
that  would  be  a  "tidy  model."  The  original  ARPANET  crew  was  inter- 
ested in  getting  things  to  actually  work,  to  push  bits  around  a  system. 
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Protocol  Wars:  Is  OSI  Finally  Dead?  (continued) 

John  Quarterman  remarked  to  me:  "OSI  specified  before  implement- 
ation. So  specification  took  forever  and  implementation  never  really 
happened,  except  for  bits  and  pieces.  In  addition,  heavy  government 
backing  (by  the  EC— now  the  EU— and  various  national  governments) 
led  some  OSI  participants  to  attempt  to  substitute  official  authority 
for  technical  capability.  OSI  and  IP  started  at  about  the  same  time 
(1977).  OSI  wandered  off  into  the  weeds  and  IP  won  the  race.  Those 
governments  that  backed  OSI  bet  on  the  wrong  horse." 

In  my  opinion,  this  last  is  the  answer:  specification  before  implement- 
ation doesn't  work.  The  necessity  of  delivering  functioning  hardware 
and  software  was  what  motivated  both  the  AKPA  team  and  the  Net- 
work Working  Group.  This  sort  of  group  was  not  involved,  beyond  the 
very  beginnings,  in  the  bureaucracy  of  ISO  and  the  creation  of  OSI. 

The  other  problem  was  that  TCP/IP  was  a  suite  with  a  real  installed 
base.  The  implementations  had  evolved  between  1974  and  1978  and 
were  widely  accepted  within  the  technical  community.  By  supporting 
a  theoretical  specification  with  no  implementation,  the  PTTs  of  Eur- 
ope and  Japan  were  both  sticking  to  the  "old"  telephony  and  tele- 
graphy way  of  thinking  at  the  same  time  they  appeared  to  be  mired  in 
the  "Not  Invented  Here"  morass.  The  US  government  had  funded  the 
ARPANET  and  it  was  largely  an  American  creation.  A  final  reason 
that  has  been  adduced  is  that  the  Japanese  and  European  govern- 
mental representatives  (all  the  PTTs  were  governmental)  didn't  want 
US  manufacturers  to  have  an  unfair  advantage,  selling  their  extant 
TCP/IP  products.  Real  money  was  involved;  future  profits  were  at 
stake. 

The  fact  that  local  area  networks  and  desktop  workstations  supported 
TCP/IP  meant  that  there  was  an  ever-increasing  infrastructure  built 
upon  TCP/IP  in  Europe.  The  changing  political  situation  in  Eastern 
Europe  and  in  the  erstwhile  USSR  also  meant  increasing  TCP/IP 
support  (as  all  the  specifications  were  in  the  public  domain  and  thus 
no  fees  were  payable).  So  far  as  I  can  tell,  while  OSI  networking  still 
exists  in  many  places,  it  is  not  waxing;  TCP/IP  networks  are. 

The  actual  result  was  that  many  companies  wasted  a  decade  trying  to 
produce  OSI  products  while  the  networking  community  increasingly 
used  TCP/IP.  While  Mischa  Schwartz  (in  1987)  could  still  beheve: 
"TCP  and  ISO  TP  class  4  will  coexist  for  some  time,  but  ...  as  more 
manufacturers  and  users  begin  to  adopt  the  ISO  suite  of  transport 
protocols,  use  of  TCP  will  begin  to  decrease";  Fred  Halsall,  a  staunch 
OSI  supporter,  has  pointed  out  "In  practice  ...  there  are  two  major 
open  system  (vendor-independent)  standards:  the  TCP/IP  protocol 
suite  and  those  based  on  the  evolving  ISO  standards"  [1992].  More 
manufacturers  and  users  haven't  adopted  the  OSI  suite. 

Now  that  NIST  has  succumbed,  the  war  has  been  won  by  TCP/IP;  I 
can  only  be  aghast  at  the  energy  and  time  that  went  into  the  protocol 
wars,  which  have  only  ended  late  in  1994,  with  the  US  government's 
recognition  of  the  de  facto  victory  by  TCP/IP. 
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The  RA  Route  Server  Service  Overview 

by  Jessica  Yu,  Merit  Network,  Inc. 

This  article  describes  the  current  Route  Server  (RS)  service  provided 
by  the  NSF-sponsored  Routing  Arbiter  (RA)  project.  Route  Servers  are 
installed  at  each  Network  Access  Point  (NAP),  the  interconnection 
points  where  many  Internet  Service  Providers  (ISPs)  and  other  net- 
works exchange  traffic.  The  purpose  of  the  RS  service  at  each  NAP  is 
to  facilitate  and  simplify  inter-domain  routing  among  the  various 
providers  attached  to  the  NAP.  The  RS  service  is  not  limited  to  the 
NAPs;  it  could  be  provided  at  any  Internet  interconnection  point  that 
shares  the  basic  functionality  of  a  NAP. 

In  this  article,  the  terms  NSP  (Network  Service  Provider)  and  ISP 
(Internet  Service  Provider)  are  used  interchangeably. 

A  NAP  Route  Server  can  be  conceived  as  a  system  that  performs  rout- 
ing processing  for  the  ISPs  connected  to  the  NAP.  The  RS  exchanges 
routing  information  with  the  routers  attached  to  the  NAP,  and  passes 
routing  information  from  one  ISP  to  another  meeting  their  policy 
requirements,  thus  allowing  direct  traffic  exchange  between  ISP 
routers  at  the  NAP.  The  Route  Server  itself  does  not  forward  packets 
or  perform  any  switching  functions  for  the  ISPs.  (See  Figure  1.) 

The  RA  Route  Server  system  is  a  Sun  SPARC  20  workstation  running 
SunOS.  Special  routing  software  developed  by  the  RA  project  per- 
forms the  routing  exchange  and  processing  functions  described  in 
detail  below.  The  RS  is  operated  by  the  RA  project,  a  joint  under- 
taking of  Merit  Network,  Inc.,  and  the  University  of  Southern  Calif- 
ornia Information  Sciences  Institute  (ISI). 

According  to  current  plans,  two  RSs  will  serve  each  NAP  to  provide 
redundant  service. 


Routing  flow 


Traffic  flow 


How  does  a  Route 
Server  work? 
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Figure  1:  Route  Server  facilitates  information  exchange 
while  not  involved  in  packet  forwarding 

The  RS  facilitates  routing  exchange  among  the  NAP-attached  ISPs  by 
gathering  routing  information  from  each  ISP  routers  on  the  NAP, 
processing  the  information  based  on  the  ISP's  routing  policy  require- 
ments, and  passing  the  processed  routing  information  to  each  ISP 
router.  Initially,  the  RS  uses  BGP-4  as  the  inter-domain  routing 
protocol  to  exchange  routing  information  with  NAP-attached  ISP 
routers. 
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As  noted  earlier,  the  RS  does  not  forward  packets  among  the  NAP- 
attached  ISPs.  The  RS  uses  BGP's  third-party  routing  information 
capabilities  to  pass  routing  information  from  one  ISP  to  another,  with 
the  next  hop  pointing  to  the  ISP  router  that  advertises  the  route  to 
the  RS.  Traffic  is  therefore  exchanged  directly  among  the  ISP  routers 
on  the  NAP,  even  though  the  routing  information  is  provided  by  the 
RS. 

The  RS  has  the  ability  to  create  a  Routing  Information  Base  (RIB), 
referred  as  a  "View"  in  RS  parlance,  for  each  ISP  router  that  peers 
with  the  RS.  The  view  created  for  a  given  ISP  maintains  routing 
information  which  meets  the  policy  requirements  of  that  particular 
ISP.  The  view  makes  it  possible  for  an  ISP  peering  with  the  RS  to 
obtain  the  same  routing  information  from  the  RS  that  it  would  if  it 
peered  with  every  other  ISP  on  the  NAP,  without  the  presence  of  the 
RS  service.  That  is,  the  RS  could  give  a  different  path  towards  a  given 
destination  to  different  ISPs,  if  such  paths  were  available  and  if  such 
policy  were  required  by  the  ISPs.  For  example,  ISP-1,  ISP-2,  ISP-A 
and  ISP-B  are  all  connected  to  a  NAP  with  the  RS.  ISP-1  and  ISP-2 
can  both  reach  destination  X.  ISP-A  prefers  to  traverse  ISP-1  to  reach 
X,  while  ISP-B  favors  to  traverse  ISP-2  to  reach  destination  X.  The  RS 
will  provide  routes  to  satisfy  both  ISP-A  and  ISP-B's  policy  needs. 
Similarly,  if  ISP-1  does  not  want  to  be  the  transit  to  destination  X  for 
the  traffic  coming  from  ISP-A,  the  RS  will  not  pass  ISP-l's  route  to 
ISP-A.  (See  Figure  2.) 

Readers  may  refer  to  [1]  for  detailed  information  about  the  design  of 
the  Route  Server. 

In  order  for  the  RS  to  tailor  its  route  processing  to  meet  the  policy 
requirements  of  an  ISP,  the  ISP  must  register  its  inter-domain  rout- 
ing policy  information  in  the  RADB  {Routing  Arbiter  Database)  pro- 
vided by  the  RA  service.  The  RADB  is  a  part  of  the  IRR  (Internet 
Routing  Registry),  a  virtual  database  currently  comprising  databases 
provided  by  RA,  RIPE,  MCI,  and  CA*net.  The  RS  will  derive  a  given 
ISP's  routing  policy  based  on  the  information  registered  in  the  IRR. 
Please  refer  to  [2]  and  [3]  for  information  about  the  RADB. 


X  via  ISP-1 


X    via  ISP-1 
X   via  ISP-2 
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_„   ___     Routing  flow 


Traffic  flow 

Figure  2:  Route  Server  does  customized  routing 
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RA  Route  Server  Service  Overview  (continued) 

"  Scalable  Routing  at  NAPs:  The  RS  facilitates  routing  information 
exchange  among  the  ISPs  attached  to  a  NAP  by  peering  with  each  ISP 
router  on  the  NAP.  Instead  of  a  full-mesh  BGP  peering  among  all  the 
ISPs  on  the  same  NAP,  the  ISPs  could  peer  only  with  the  RS,  and  still 
achieve  the  goal  of  full  routing  exchange  with  the  other  ISPs.  The  RS 
thus  reduces  the  number  of  peering  sessions  each  ISP  router  needs  to 
process  from  Oin)  to  0(1). 

Note  that  in  addition  to  peering  with  the  RS,  ISP  routers  may  also 
optionally  peer  with  each  other  if  so  desired. 

*  Simplified  Routing  Processing  on  ISP  Routers:  The  RS  processes 
routing  information  based  on  the  routing  policy  described  by  each 
ISP.  This  includes,  but  is  not  limited  to,  route  filtering  for  a  particular 
ISP,  selection  of  the  desired  path  towards  all  destinations  the  ISP  will 
be  reaching,  etc.  This  will  greatly  reduce  routing  processing,  filtering 
and  configuration  management  for  ISP  routers  at  the  NAPs. 

The  RS  will  not  distribute  routes  learned  from  one  ISP  to  another  ISP 
without  the  permission  of  both.  This  permission  will  be  expressed  in 
terms  of  the  ISP's  routing  policy  registered  in  the  IRR. 

*  Insertion  of  the  RS  Autonomous  System  (AS)  Number  in  the 
Routing  Path:  The  RS  can  be  configured  to  insert  or  suppress  its  own 
AS  number  in  the  AS  path  when  passing  routes  from  one  ISP  to 
another  via  BGP.  This  option  is  configurable  on  a  peer-by-peer  basis, 
and  is  configured  according  to  the  wishes  of  each  ISP.  This  means 
that  the  Route  Server  could  be  viewed  transparently  when  passing 
routing  information. 

®  Handling  of  Multi_Exit_Discriminator  (MED):  The  RS  is  able  to 
pass  along  the  Multi_Exit_Discriminator  (MED)  attribute  defined  in 
BGP  protocol  specification  with  no  modification.  Passing  unmodified 
MED  value  allows  traffic  exchange  between  pair  of  ISPs  using  the 
MED  as  if  they  directly  peered  with  each  other. 

The  RS  is  also  able  to  assign  a  MED  to  routes  advertised  by  an  ISP 
with  a  value  specified  by  the  ISP  when  passing  them  to  other  ISPs. 
This  provides  an  ISP  with  the  ability  to  apply  desirable  MED  values 
towards  selected  ISPs. 

*  Route  Flapping  Damping  Mechanism:  A  route  flapping  damping 
mechanism  will  be  implemented  in  the  RS  to  reduce  the  impact  of 
frequent  route  flapping  on  ISP  router  performance. 

»  Redundancy:  According  to  current  plans,  two  RSs  will  serve  each 
NAP  to  provide  fault  tolerance. 

Based  on  the  RS  functions  described  above,  the  RS  at  NAP  offers  the 
following: 

®  Scalable  Routing  at  NAPs:  As  mentioned  earlier,  ISP  routers  on  a 
NAP  would  need  to  establish  full-mesh  BGP  peer  sessions  among 
themselves  in  order  to  exchange  routing  information  without  the 
presence  of  the  RS.  That  is,  if  there  were  N  ISPs  present  at  a  NAP, 
each  would  have  N-1  peering  sessions.  When  iV  is  a  large  number,  a 
sizable  load  could  be  placed  on  each  router  in  order  to  maintain  the 
required  peering  sessions  and  process  the  needed  routing  information. 
With  the  RS,  each  ISP  only  needs  to  peer  with  one  RS — or  two  for 
backup  purposes — instead  of  maintaining  A^-1  peer  sessions. 
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"  Separation  of  Routing  and  Forwarding:  If  a  NAP  did  not  have  a 
Route  Server,  each  ISP  router  would  need  to  perform  two  major 
functions  at  all  times:  route  processing  and  packet  forwarding.  A 
heavy  traffic  load  could  put  a  substantial  extra  burden,  which  would 
also  need  to  process  routing  information.  The  load  would  be  particul- 
arly heavy  if  the  number  of  peering  sessions  was  not  small,  the 
number  of  destination  routes  was  large,  and  the  policy  was  complic- 
ated. It  would  be  ideal  to  have  the  routers  concentrate  on  forwarding 
packets,  and  have  another  system  handle  routing.  The  Route  Server 
achieves  just  this  goal:  it  processes  routing  information  for  each  ISP's 
router,  thus  enabling  the  ISP  routers  to  concentrate  on  packet 
switching. 

®  Simplified  Routing  Configuration  Management  on  ISP's  Routers: 
The  RS  processes  routing  information  based  on  the  routing  policy 
defined  by  each  ISP.  This  includes  route  filtering,  e.g.,  setting  up 
routing. firewalls,  selecting  the  desired  path  towards  all  destinations 
the  ISP  will  be  reaching  and  other  tasks.  These  routing  tasks  would 
normally  be  configured  and  implemented  on  the  ISP  routers.  There- 
fore, the  RS  would  greatly  reduce  the  routing  processing,  filtering  and 
configuration  management  load  on  the  ISP  routers  at  the  NAPs. 

It  should  be  noted  that  RS  not  only  can  be  used  for  some  complicated 
routing  policies  but  also  can  be  used  to  facilitate  simple  routing 
policies.  An  ISP's  policy  could  be  as  simple  as  to  accept  all  the  routes 
advertised  by  another  ISP  at  a  NAP. 

®  Enforcing  Good  Routing  Engineering:  The  RS  provides  more  flexi- 
bility in  terms  of  adding  new  mechanisms  or  techniques  to  its  routing 
code  than  many  commercial  vendors.  Peering  with  the  RS  may  there- 
fore provide  a  quick  fix  to  urgent  problems.  For  example,  route  flap- 
ping consumes  a  great  deal  of  precious  router  processing  time,  and  is 
currently  a  major  routing  engineering  concern.  The  Route  Server  can 
help  reduce  the  effects  of  route  flapping  by  implementing  a  route 
damping  mechanism  in  the  RS. 

All  NAP-attached  ISPs  are  entitled  to  RS  services  at  this  stage.  The 
RS  will  peer  with  anyone  who  requests  to  peer  with  it,  providing  the 
ISP  agrees  with  the  conditions  described  in  "The  Routing  Arbiter 
Peering  Agreement."  [4]. 

Technically,  the  ISP  needs  to  meet  certain  conditions  in  order  to  peer 
with  the  RS.  The  ISP  is  also  required  to  use  the  modern  Inter- 
Domain  Routing  Protocol  (IDRP)  to  exchange  routing  information 
with  the  RS  and  register  its  policy  information  in  the  IRR,  so  the  RS 
can  process  routing  information  based  on  the  particular  ISP's  routing 
policy. 

In  order  to  peer  with  the  RS,  the  ISP  administrator  should  submit  a 
"Route  Server  Peering  Session  Request  Template"  [5]  via  e-mail  to 
rs-peer@ra.net.  Upon  receiving  each  request,  the  RS  will  be  con- 
figured to  peer  with  the  router.  The  routing  exchange  policy  will  be 
based  on  the  routing  policy  description  of  the  AS  associated  with  this 
router,  and  is  expected  to  be  registered  in  the  IRR.  In  the  absence  of 
the  related  AS  policy  information  in  the  IRR,  the  RS  will  be  con- 
figured to  peer  with  the  router  with  a  simple  default  policy.  By 
default,  the  RS  will  not  distribute  the  routes  advertised  by  this  peer 
to  other  ASs,  nor  will  it  distribute  routes  from  other  ISPs  to  the  peer. 

The  requestor  will  need  to  make  the  proper  configuration  on  its  own 
NAP-attached  router  in  order  for  its  router  to  establish  a  peering 
session  with  the  RS. 

continued  on  next  page 
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BA  Route  Server  Service  Overview  (continued) 

As  mentioned  above,  the  purpose  of  the  NAP  Route  Servers  is  to 
faciUtate  and  simplify  routing  among  the  NAP-attached  service  pro- 
viders. Among  the  advantages  of  using  the  RS  service  at  NAP  are 
scalable  routing  and  optimum  use  of  an  ISP  router's  CPU  power  cycle 
for  packet  switching,  by  leaving  routing  processing  tasks  to  the  RS. 
The  RS  function  and  service  will  be  evolving  with  more  operational 
experience  and  feedback  from  ISPs  and  the  Internet  community. 

The  RA  Route  Servers  are  currently  deployed  at  MAE-East  provided 
by  MFS,  the  New  York  area  NAP  provided  by  Sprint,  the  Pac*Bell 
NAP  in  San  Francisco,  the  Ameritech  AADS  NAP  in  Chicago,  and  at 
MAE-West  in  the  San  Francisco  area. 

Special  thanks  to  Susan  Harris  of  Merit  for  editing  and  polishing  the 
text  of  this  document.  Many  thanks  to  Jon  Postel,  Cengiz  Alaettinoglu 
of  ISI  for  their  constructive  and  helpful  comments. 
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FDDI:  A  High  Speed  Network,  by  Amit  Shah  and  G.  Ramakrishnan. 
Prentice  Hall,  Englewood  Cliffs,  NJ  07632,  1994.  ISBN  0-13-308388-8. 

In  the  midst  of  al  the  hype,  frenzy,  and  fascination  over  ATM,  one 
might  be  tempted  to  ask  whether  FDDI  is  still  relevant.  The  simple 
truth  is  that  FDDI  not  only  remains  relevant,  but  it  is  providing  high 
speed  networking  solutions  in  scenarios  where  current  generation 
ATM  switching  technology  has  not  yet  lived  up  to  expectations. 
Certain  vBNS  NAPs,  commercial  interconnects,  and  enterprise  inter- 
net equivalents  use  FDDI  to  interconnect  high-end  routers  in  those 
circumstances  where  the  number  of  T3  circuits  terminated  at  a  single 
site  exceeds  any  single  router's  capacity.  FDDI  is  also  used  as  a  cam- 
pus backbone  solution  and  as  an  upgrade  LAN  technology  for  NOS 
servers  in  enterprise  nets.  And  FDDI  is  certain  to  play  a  role  in  the 
evolution  to  switched  internetworking.  So  I'd  say  FDDI  is  relevant  and 
will  remain  so  for  some  time. 

The  criteria  for  whether  a  book  on  FDDI  remains  relevant  are  some- 
what different  than  those  on  ATM.  Books  covering  ATM  may  still  be 
relevant  if  they  focus  on  standards  and  theory,  but  FDDI  standards 
are  nearly  10  years  old,  and  papers  describing  the  Time  Token 
Rotation  protocol  on  which  FDDI  is  based  appeared  in  1982,  so  one 
would  hope  that  any  book  competing  for  shelf  space  today  would 
address  the  practical  aspects  of  FDDI. 

Thankfully,  Amit  Shah  and  G.  Ramakrishnan  do  a  rather  good  job 
providing  relevant  material  in  this  book.  In  fact,  you  have  to  look  hard 
to  find  in-line  references  to  standards.  Four  chapters  describe  FDDI 
nodes  and  topologies,  the  MAC,  physical,  and  physical  media  depen- 
dent layers  in  ample  if  not  painstaking  detail,  and  diagrams  modeling 
operational  flows  complement  the  text  nicely.  The  chapter  on  Station 
ManagemenT  (SMT)  does  an  admirable  job  of  explaining  link  and 
node  management  in  as  close  to  "plain-speak"  as  one  could  expect. 
The  practical  aspects  of  FDDI — issues  to  consider  when  selecting 
media,  installing  cabling,  and  when  choosing  a  topology — are  covered 
in  the  closing  chapters.  The  final  chapter  provides  guidelines  for 
troubleshooting  FDDI  networks.  These  are  probably  the  most  inter- 
esting and  valuable  chapters,  especially  for  those  who  are  installing 
FDDI. 

The  typical  Connexions  reader  may  find  the  chapter  describing  inter- 
networking with  FDDI  rather  mundane,  and  may  not  appreciate  the 
somewhat  lackadaisical  treatment  of  SNMP  and  CMIP  in  the  chapter 
on  remote  network  management  (the  authors  show  a  bias  towards 
SMT  which  is  not  universally  shared,  and  relegate  SNMP,  et.  al.  to  a 
subsection  entitled  "FDDI  Management  with  Other  Protocols").  The 
propensity  of  the  authors  to  intermingle  discussion  of  Internet  and 
OSI  technology  without  clearly  distinguishing  between  the  two  was 
something  of  a  frustration,  and  the  introductory  chapters  are  dis- 
connected, but  I  would  not  denounce  this  book  on  the  basis  of 
"occasional  inaccuracies"  and  a  slow  start. 

In  the  Preface,  the  authors  promise  "a  book  which  is  neither  too  tech- 
nical nor  too  simplistic."  On  balance.  Shah  and  Ramakrishnan  del- 
iver. If  you  have  no  knowledge  or  experience  with  FDDI,  you  should 
consider  adding  this  book  to  your  library. 

— David  M.  Piscitello, 

Core  Competence,  Inc. 

dave@corecom . com 
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Ainiouncement  and  Call  for  Papers 

The  7th  Joint  European  Networking  Conference  (JENC7)  will  be  held  O 
in  Budapest,  May  13-16  1996.  The  event  is  organized  by  TERENA, 
the  Trans-European  Research  and  Education  Networking  Association, 
with  the  local  assistance  of  the  Hungarian  Academy  of  Sciences  and 
HUNGARNET.  The  theme  of  the  conference  is  "The  Role  of  Research 
Networking  in  the  Information  Society."  In  line  with  the  established 
tradition  of  the  previous  JENCs  this  7th  JENC  aims  at  bringing 
together  individuals  from  research  and  education,  industry  and  govern- 
ment who  are  involved  with  planning,  developing,  implementing, 
managing,  funding,  and  using  national,  regional  and  international 
computer  networks  for  a  four  day  meeting  in  which  state  of  the  art 
networking  issues  will  be  presented,  discussed  and  demonstrated. 

Topics       The  following  subject  areas  define,  not  exclusively,  possible  topics  for 
paper  submission: 

®  User  Support  and  Education: 
Support  of  tele-collaboration 
Publishing  issues  in  the  Information  Society 
Globalization  of  user  support  services 
Virtual  education  and  learning  communities 
Networked  scientific  research  and  its  applications 
K-12 

Work  and  play  in  Cyberspace 
User  education  tools 
Networked  information  retrieval 
Library  access  in  the  Information  Society 

®  Policy,  Economic  and  Societal  Issues:  ','/ 

Networking  developjnents  in  technologically  emerging  countries 
Technology  transfer  to  technologically  emerging  countries 
Funding  and  pricing  models  for  networks  and  networking  services 
Commercialization,  privatization  and  public  access 
Electronic  communities  and  the  law 
Copyright  and  intellectual  property  rights  issues 
Privacy  and  data  protection 
Governments  and  the  Information  Society 
Effects  of  Telecommunication  Liberalization 

*  Network  Engineering: 
Building  the  Information  Society 

Application  of  network  technology  to  provide  networking  services 
International  interoperability  and  network  management  issues 
Network  management  systems  and  methods 
Reliability,  performance  and  scaling  issues 
Network  security  mechanisms  and  incident  handling 

•  Network  Technology: 

New  and  international  open  network  protocols 
Transmission,  routing,  and  transport  technologies 
Multicast  developments 
High  speed  WANs 
Mobility  developments 

®  Application  Technology: 
Network  application  infrastructure 
Computer  supported  collaborative  work 
Interoperability  of  application  services 
Distributed  applications'  management 
Security  aspects  of  distributed  applications 
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Submissions 


Important  dates 


Publications 


Workshop  and  tutorials 


Working  group 
presentations 


Exhibition 


Venue 


More  information 


®  Infrastructure  developments: 
European  backbone  developments 
ATM 
34  Mbps  and  beyond 

All  papers  must  be  written  in  English.  Electronic  submission  is  highly 
recommended  and  should  take  place  as  follows: 

®  ASCII  or  uuencoded  PostScript:  send  by  e-mail  to: 
jenc7-submit@terena.nl 

®  PostScript  documents:  send  by  anonymous  FTP  to  Internet  host 
erasmus.terena.nl  (IP  address  192.87.30.2),  into  the  directory 
pub/ jenc7/submit.  Please  note  that  files  deposited  in  this  direc- 
tory can  only  be  written  once  and  cannot  be  deleted  afterwards. 

There  will  be  the  opportunity  for  participants  to  present  exciting 
applications  of  networking  services  in  the  form  of  a  demonstration. 
Proposed  demonstrations  should  be  documented  with  a  description 
not  exceeding  one  page. 


Full  manuscript  due: 
Proposals  for  demonstrations  due: 
Notification  of  acceptance  to  authors: 
Camera-ready  papers  due: 


November  19,  1995 
November  19,  1995 
January  15,  1996 
March  31,  1996 


Conference  proceedings  containing  full  papers  will  handed  out  to  the 
participants.  A  selection  of  the  best  papers  will  be  published  as  a 
special  issue  of  Computer  Networks  and  ISDN  Systems. 

The  traditional  Network  Technology  Training  Workshop  will  be  held 
the  week  prior  to  the  conference.  Travel  and  tuition  support  may  be 
available  for  selected  attendees.  Additional  information  is  available 
from  the  JENC7  Secretariat  at  the  address  below.  Tutorials  are 
planned  to  be  held  on  May  13  (morning)  and  May  16  (afternoon)  as 
well  as  May  17  (full  day). 

There  will  be  provisions  for  presentations  describing  the  activities  in 
TERENA  Working  Groups  and  IETF  Areas.  The  participants  in  the 
EC's  4th  FW  Programme  are  invited  to  present  progress  reports 
and/or  planned  activities — in  the  realm  of  the  TERENA  coordinated 
SCIMITAR  project. 

An  exhibition  area  will  be  available  for  International  and  Hungarian 
companies  and  institutions  for  demonstration  of  their  products  and 
services. 

The  premises  of  the  Hungarian  Academy  of  Sciences,  one  of  the  most 
beautiful  historical  buildings  of  Budapest,  will  accommodate  the  plen- 
ary sessions,  most  parallel  technical  sessions  and  the  networking 
facilities  of  the  conference.  The  TERENA  Working  Groups  will  also 
meet  here.  Within  3  minutes  walk  of  the  Academy  of  Sciences,  the 
Danube  Palace  provides  several  attractive  meeting  rooms  in  neo- 
baroque  style.  This  building  will  house  the  rest  of  the  technical 
sessions,  special  meetings,  the  demonstrations  and  lunch. 


JENC7  Secretariat 
c/o  TERENA  Secretariat 
Singel  466-468 
NL-1017  AW  Amsterdam 
THE  NETHERLANDS 


JENC7  Local  Organization 
c/o  MTA  SZTAKI 
Kende  u.  13-17 
H-1111  Budapest 
HUNGARY 


jenc7-sec@terena.nl  richter@sztaki.hu 

ht tp : / /www . terena . nl / terena/ j  enc7 /      http : / /www . i  if . hu/ j  enc / 
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50,000  networks 


Internet  Survey  Reaches  6.6  Million  Host  Level 
First  Half  1995  Growth  is  37  Percent 

Reston  VA,  USA,  August  2,  1995— The  latest  results  from  the  Inter- 
net's most  basic  and  longest  continuing  measurement  of  its  size  were 
just  released  by  Mark  Lottor  of  Network  Wizards  of  Menlo  Park,  CA, 
USA.  The  Domain  Survey  attempts  to  discover  every  host  on  the 
Internet  by  doing  a  complete  search  of  the  Domain  Name  System.  The 
latest  results  were  gathered  during  late  July  1995.  The  data  is  avail- 
able in  the  zone  directory  on  ftp. nw. com,  or  http://www.nw.coin. 

The  Internet  is  a  very  complex,  dynamic,  distributed  aggregation  of 
more  than  50  thousand  autonomous  networks.  It  defies  definitive 
measurement.  Nonetheless,  these  values  constitute  prima  facie  con- 
nected host  computers,  even  if  many  might  not  always  be  reachable, 
and  Lottor  has  carefully  conducted  these  counts  over  many  years. 
They  are  also  extremely  valuable  for  relative  comparisons. 

The  Internet  Research  Task  Force  (IRTF)  Survey  Working  Group 
(SWG)  is  analyzing  these  statistics  and  methodologies  to  detect  anom- 
alies and  produce  additional  information. 

Highlights       Newsworthy,  strategic  highlights  of  the  most  current  values  include: 

®  Very  slightly  decreased,-  but  continued  strong  exponential  growth 
rate.  At  the  average  rate  of  increase  over  the  past  14  quarters,  the 
total  projected  hosts  at  the  end  of  the  decade  is  101  million. 

®  Hosts  in  106  country  domains  were  counted,  an  increase  in  15 
countries.  (Note  that  verification  has  not  been  performed  to  verify 
that  these  hosts  are  physically  located  in  the  country.) 

®  The  global  commercial  domain  .  COM  continues  not  only  to  be  the 
largest,  but  continues  growing  at  a  rapid  rate. 

®  Germany  and  Japan  are  exhibiting  very  rapid  growth  rates 
among  industrialized  countries  with  a  first  half  rates  of  41%  and 
40%,  respectively. 

*  In  absolute  terms,  the  USA  had  the  largest  jump  of  about 
1,090,000  hosts— a  rate  of  24%.  The  USA  values  are  subject  to 
inherent  uncertainties  because  of  the  mix  of  3-letter  global  dom- 
ains and  the  .  US  domain. 

®  Strong  Russian  Federation  growth  continues  at  a  68%  half  year 
rate. 


Details 


®  Most  regional  growth  rates  throughout  the  world  continue  at 
averages  exceeding  40  percent. 

Updated  color  graphs  of  these  trends,  including  those  for  most 
countries  are  available  at: 


About  ISOC 


ftp :  //ftp .  isoc . org /isoc /charts /host s4  .ppt  (PowerPoint  v.4) 
ftp:  //ftp.  isoc.org/isoc/charts/hosts3.ppt   (PowerPoint  v.3) 

The  Internet  Society  is  an  International  individual  membership  orga- 
nization for  the  Internet  global  cooperation.  Its  International  Secre- 
tariat can  be  reached  at: 

12020  Sunrise  Valley  Drive,  Suite  210 
Reston,  VA,  USA 

isoc@isoc.org  http://www.isoc.org 

Tel:  +1  703  648  9888     Fax:  -hi  703  648  9887 
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Topics 


Submissions 


Publication  and 
presentation 


Call  for  Papers 

The  NetWorld+Interop  US  Program  Committee  is  pleased  to  solicit 
original  technical  papers  for  the  3rd  annual  Interop  Engineers'  Con- 
ference, held  in  conjunction  with  the  NetWorld+Interop  Conference 
and  Exhibition,  from  April  1st  through  5th,  1996. 

In  order  to  focus  discussion  and  interaction,  this  year  the  Engineers' 
Conference  is  focusing  on  six  topic  areas  of  interest  in  computer- 
communications  : 

®  Resource  Management  over  Heterogeneous  Networks 

®  Cell-based  Routing 

®  Traffic  management  and  the  future  of  Congestion  Control 

®  Distributed  Applications  Management 

®  Video  over  Enterprise  Networks 

®  High-speed  Packet  Filtering  and  Firewalling 

A  detailed  description  of  each  topic  area  can  be  found  at  URL 
http; //www. interop.com.  This  conference  seeks  to  bring  together 
research  scholars,  engineers,  and  vendors  to  address  pragmatic  engin- 
eering issues  in  the  field  of  networking  and  distributed  systems  inter- 
operability. It  is  an  excellent  forum  for  engineers  and  researchers  to 
publish  papers  on  solutions  to  today's  engineering-related  problems. 

Interested  parties  should  submit  abstracts  of  their  papers  by  Septem- 
ber 8,  1995.  An  abstract  should  be  500-1,000  words  in  length  and  con- 
vey the  key  aspects  of  the  paper.  All  abstracts  should  be  submitted  in 
ASCII.  The  program  committee  will  indicate  its  acceptance  (or  not), 
no  later  than  September  22,  1995.  To  submit  an  abstract,  send  a  mes- 
sage: 

To:  engrconf@interop.com 
Subject:  abstract 

(Do  not  put  anything  else  in  the  Subject:  line.)  The  message  should 
contain  your  complete  contact  information  (name,  affiliation,  postal 
address,  telephone,  facsimile,  and  e-mail)  along  with  your  abstract. 
An  automated  reply  will  confirm  receipt  of  your  abstract. 

If  an  abstract  is  accepted,  the  author(s)  should  submit  a  first  draft  of 
their  paper  by  December  31,  1995.  A  paper  should  be  between  10  to  16 
pages  in  length,  and  be  written  in  technical  English.  All  papers 
should  be  submitted  either  in  ASCII  or  PostScript.  The  program  com- 
mittee will  indicate  its  acceptance  (with  comments)  or  not,  on  Janu- 
ary 19,  1996. 

If  a  paper  is  accepted,  the  author(s)  should  submit  the  final  copy  of 
their  paper,  reflecting  the  comments  of  the  program  committee  by 
February  23,  1996.  All  final  copies  will  be  published  in  the  event  pro- 
ceedings. Upon  receipt  of  the  final  copy,  the  program  committee  will 
inform  the  author(s)  if  their  papers  are  to  be  presented  at  the  event. 
Presentation  should  be  20-25  minutes,  excluding  questions. 

Note  that  although  every  author  who  submits  a  final  copy  of  an  accep- 
ted paper  receives  a  complimentary  admission  to  the  Engineers'  Con- 
ference as  well  as  the  NetWorld+Interop  General  Conference  and  Ex- 
hibition, there  may  not  be  sufficient  speaking  slots  for  each  accepted 
paper. 
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Hyperspeed 


Program 


Partners 


More  information 


NetWorld+Interop  expands  to  London  and  Sydney 

SOFTBANK  Exposition  and  Conference  Company  recently  announced 
that  they  will  be  adding  London  and  Sydney  to  their  conference  and 
exhibition  "World  Tour."  This  brings  to  seven  the  total  number  of 
NetWorld+Interop  events  for  1996.  On  October  28  through  November 
1,  1996  networking  and  interoperability  hardware,  software  and  trans- 
port technology  products,  services  and  applications  will  converge  at 
Earls  Court  2  for  NetWorld+Interop  96  London,  the  first  UK-based 
NetWorld+Interop  Conference  and  Exposition.  Down  under,  a  similar 
event  entitled  NetWorld+Interop  96  Sydney  will  be  held  November 
25-29,  1996  at  the  Sydney  Exhibition  and  Conference  Centre,  Darling 
Harbour. 

"The  hyperspeed  of  the  development  of  this  market  requires  an  on- 
going, global  arena  in  which  network  professionals  can  learn,  touch 
and  test  the  latest  products  and  technologies.  NetWorld+Interop 
attendees  will  be  able  to  talk  directly  with  technology  experts  and 
executives  from  leading  companies  and  gain  valuable  hands-on  ex- 
perience with  the  newest  products  on  our  interactive  show  floor," 
explained  Michael  D.  Millikin,  Sr.  Vice  President,  NetWorld+Interop. 
"These  are  also  the  ideal  venues  for  vendors  who  need  to  reach  UK- 
based  and  Australia-based  network  computing  professionals." 

A  full  schedule  of  tutorials,  conferences,  workshops,  technology  dem- 
onstrations, and  exhibits  will  provide  attendees  with  access  to  the 
largest  pool  of  networking  hardware,  software  and  transport  products, 
services  and  applications  assembled  under  one  roof — at  all  seven 
events. 

NetWorld+Interop  is  the  most  comprehensive  event  in  the  networking 
industry.  It  is  the  summit  for  interoperability,  bringing  together  the 
products,  services  and  applications  networking  professionals  need  and 
offering  the  highest  quality  courses  led  by  industry  experts,  including 
the  original  Internet  developers,  technology  inventors  and  leading 
reference  authors.  This  event  was  firmly  established  as  "The  Net- 
working Summit"  with  its  1994  debut,  and  is  the  global  gathering 
place  for  the  industry's  best  and  brightest  networking  professionals. 
The  NetWorld+Interop  1994  World  Tour  was  a  success  with  events  in 
Las  Vegas,  Berlin,  Tokyo,  Atlanta  and  Paris. 

SOFTBANK  Expos  has  retained  Real  Time  Events  Ltd  to  jointly 
produce  NetWorld+Interop  96  London.  Real  Time  Events  has  over  50 
years  of  combined  trade  show  experience  with  its  IT  event  profes- 
sionals. In  Australia  NetWorld+Interop  96  Sydney  will  be  produced 
jointly  with  Synergy  Conventions.  Synergy  Conventions  produces 
more  than  100  conferences  in  Australia,  including  information  tech- 
nology and  telecommunications  conferences. 

For  information  on  exhibiting  at  NetWorld+Interop  96  London  call 
David  Conn  at  Real  Time  Events  on  +44  181  849  6260.  For  inform- 
ation on  exhibiting  at  NetWorld+Interop  96  Sydney  call  Elena  Cohen 
at  Synergy  Conventions  on  +61  2  369-1242. 

NetWorld+Interop  96  Sydney  is  the  only  Australian  networking 
event,  following  the  discontinuation  of  IDG's  Network  World  in  1995. 
IDG  will  become  an  official  co-sponsor  of  the  NetWorld+Interop 
Sydney  event  and  additional  co-sponsorships  are  being  defined. 

NetWorld+Interop  information  is  available  on-line  through  the  World- 
Wide  Web  at http: //www. interop.com. 
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Future  NetWorld+Interop  Dates  and  Locations 


rl-  IHf  EaOP^  95 


More  information 


NetWorld+Interop  95 
NetWorld+Interop  95 

NetWorld+Interop  96 
NetWorld+Interop  96 
NetWorld+Interop  96 
NetWorld+Interop  96 
NetWorld+Interop  96 
NetWorld+Interop  96 
NetWorld+Interop  96 


Paris,  France 
Atlanta,  GA 

Las  Vegas,  NV 
Frankfurt,  Germany 
Tokyo,  Japan 
Atlanta,  GA 
Paris,  France 
London,  England 
Sydney,  Australia 


September  11-15,  1995 
September  25-29,  1995 

April  1-5,  1996 
June  10-14,  1996 
July  15-19,  1996 
September  16-20,  1996 
September  23-27,  1996 
Oct  28-Nov  1, 1996 
November  25-29,  1996 


All  dates  are  subject  to  change. 


Call  1-800-INTEROP  or  1-415-578-6900  for  more  information.  Or 
send  e-mail  to  info@interop.com  or  fax  to  1-415-525-0194.  For  the 
latest  information  about  NetWorld+Interop  including  A''+/  Online!  as 
well  as  other  SOFTBANK  produced  events,  check  our  home  page  at 
httpi  / /wvjvr.  interop.com 

NetWorld+Interop  is  produced  by  SOFTBANK  Exposition  and  Confer- 
ence Company,  303  Vintage  Park  Drive,  Foster  City,  California 
94404-1138,  USA. 


Subscription 
information 


Write  to  Connexions  I 

We'd  love  to  hear  your  comments,  suggestions  and  questions  about 
anything  you  read  in  Connexions.  Our  editorial  address  is  given 
below.  Use  it  for  letters  to  the  Editor,  requests  for  the  index  of  back 
issues,  questions  about  particular  articles  etc.: 

Connexions — The  Interoperability  Report 

303  Vintage  Park  Drive 

Suite  201 

Foster  City 

California  94404-1138 

USA 

Phone:  +1  415-578-6900  or  1-800-INTEROP  (Toll-free  in  the  USA) 

Fax:       +1 415-525-0194 

E-mail:  connexions@interop.com 

URL:     http://www.interop.com 

For  questions  about  your  subscription  please  call  our  customer  service 
hotline:  1-800-575-5717  or  +1  610-565-6864  outside  the  USA.  This  is 
the  number  for  our  new  subscription  agency,  Seybold  Publications. 
Their  fax  number  is  +1  610-565-1858.  The  mailing  address  for  sub- 
scription payments  is:  P.O.  Box  976,  Media,  PA  19063-0976. 


This  publication  is  distributed  on  an  "as  is"  basis,  without  warranty.  Neither  the 
publisher  nor  any  contributor  shall  have  any  liability  to  any  person  or  entity  with 
respect  to  any  liability,  loss,  or  damage  caused  or  alleged  to  be  caused,  directly  or 
indirectly,  by  the  information  contained  in  Connexions — The  Interoperability 
Report® 
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